-
Notifications
You must be signed in to change notification settings - Fork 18
Add example deploy script #50
base: main
Are you sure you want to change the base?
Conversation
Thank you!
Is the
I wouldn't mind adding solenv as a requirement! Seems useful and a good practice to avoid manually juggling credentials. Any thoughts on how we might extract some of the deploy script output into the deploy JSON files? e.g. contract addresses, etc. |
I saw it from the example in the scripting docs and found it useful. I didn't see a need for any of the outputs/ABIs in the front-end Dapp. https://book.getfoundry.sh/tutorials/solidity-scripting?highlight=Scr#solidity-scripting
I can add!
The broadcast outputs chunky json files, but they include all the correct information in a deterministic output file. Could just switch the path to those. Or could write a small script to parse the required output and write to the deploy files. Happy to hack on something and add to this PR : ) |
We could probably use the same
It'd be so great if this could be encapsulated in Solidity somehow so we don't have to run/maintain a separate script, but I'm happy with some of both if it means using Solidity scripting sooner than later! |
fwiw building a contract address book file from the foundry outputs was also my best solution so far. I also dislike checking in the full broadcasts because they're so noisy, but that feels like the right pattern for history and being able to rebuild the address book #checkingate continues |
@holic Added a jq line to the Deploy.sh script that will copy the relevant broadcast output to the existing "deploys" folder to remove the need for some manual copy/paste. |
@@ -0,0 +1,27 @@ | |||
# Expects jq to be installed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you think about replacing the contracts/deploy.sh
with this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think both are unnecessary : )
Do you want to try out the new deploy script a few times, and if it looks good, one of us pushes an update to remove the existing one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you share more about why both are unnecessary? The shell script is/was partly there to deploy the contract (now replaced by this solidity script 🙏 ) but also partly there to track the addresses for each contract so that the app, etc. can import them for wiring up contract interactions in the frontend. Is there another approach you're thinking for the latter step?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I misunderstood the question / answered it poorly : )
I thought you referring to having both the deploy.sh file in the project root and also having one in the scripts folder. I think having at least one shell script is still necessary, but having two that do the same thing is not necessary. With anything that requires multiple flags or options to remember, I love have a easy script file to wrap all that up into a single command.
This adds a working deploy script and also has an example of deploying a renderer along side the contract. In addition, it updates the following: